In general, policy control is a known process in networks such as communication networks, whereby a policy control entity indicates to a policy enforcement entity e.g. how to control bearer resources. In an IP-based (IP: Internet Protocol) network environment, such as an IP Connectivity Access Network (IP-CAN), the IP-CAN bearer may be controlled by way of policy control. Policy control may include QoS (quality of service) control, gating control and the like.
In current specifications of the 3rd Generation Partnership Project (3GPP), several policy control mechanisms are standardized or under standardization. Although the present invention described below is not restricted to any specific policy control mechanism, the following mechanisms may be mentioned as examples.
In specifications 3GPP TS 23.203, TS 29.212, TS 29.213 and TS 29.214, there is defined “Policy and Charging Control” (PCC). The PCC mechanism basically combines functionalities of its predecessors which are “Service Based Local Policy” (SBLP) and “Flow based Charging” (FBC).
All of the above-mentioned mechanisms assume that a so-called application function (AF), i.e. an element offering application(s) that use IP bearer resources, provides information about a service to some policy control node. The policy control node then uses this information to instruct a policy enforcement node e.g. being located within some kind of gateway to configure and/or authorize bearer resources according to the needs of the requested service, to configure service-specific charging of media flows associated with a requested service and/or to install IP flow filters that prevent the usage of bearer resources for unwanted services. In this regard, an IP flow means a unidirectional flow of IP packets with the same source IP address and port number and the same destination IP address and port number, and the same transport protocol port numbers are only applicable if used by a transport protocol. Currently, the provisioning of each service information (which may include information about an AF session, e.g. application identifier, type of media, bandwidth, IP address and port number) from the application function triggers the policy control node to instruct the policy enforcement node to configure and/or authorize bearer resources, to configure service-specific charging of the media flows, and/or to install IP flow filters. The policy control node shall provision e.g. PCC rules to the policy enforcement node.
As one example, the information about requested services, which the application function derives and sends to the policy control node, may be provided by way of a “Session Description Protocol” (SDP, as e.g. defined in IETF RFC 4566 and RFC 3264), as transported within a call control according to a “Session Initiation Protocol” (SIP, as e.g. defined in IETF RFC 3261). As the use of SDP/SIP signalling is widely spread in modern networks, such as for example in an IP Multimedia Subsystem (IMS), such a signalling is utilized in the following as a non-limiting example for session signalling.
According to SDP/SIP-based session signalling, as e.g. defined in IETF RFC 3264, signalling payload may be distinguished as being of offer type or of answer type. In the offer/answer model, one participant offers the other a description of the desired session from its perspective, and the other participant answers with the desired session from its perspective. Thus, a negotiation of service properties is effected. This offer/answer model is most useful in unicast sessions where information from both participants is needed for the complete view of the session, as e.g. in policy control.
In currently specified policy control procedures, as e.g. defined in specifications 3GPP TS 29.213 and TS 29.214, an application function provides service information only after receiving an SDP answer, but not already after receiving a preceding SDP offer. This is however disadvantageous for modern networks as such procedures need more time in order to handle (e.g. reject) a requested service.
In order to overcome the disadvantage of currently specified policy control procedures, there are recently discussed related procedures. For the IMS for example, a proxy call session control function (P-CSCF) acting as an application function needs to provide requested service information to the policy control node already when receiving an SDP offer (see e.g. IETF RFC 3264) within SIP in order to be able to reject the SIP session with appropriate SIP messages, if the policy control node rejects the requested service information.
In contrast to these recently discussed procedures differing from currently specified procedures, the current procedures have the advantage that the service information derived from the SDP answer is better suited to configure and/or authorize bearer resources, to configure service-specific charging of media flows, and/or to install IP flow filters. This is due to the following drawbacks of the recently discussed procedures.
Firstly, the SDP offer is usually contained in a SIP INVITE request that is forwarded by the P-CSCF at the beginning of the call setup before the call reaches the callee, who may be not reachable. Thus, a considerable fraction of call attempts will fail after this point in time. This fraction may be reduced when the SDP answer is received, as the SDP answer is sent by the callee's terminal, thus guaranteeing that the callee is reachable.
Secondly, the SDP answer reflects the media for a service to be used more correctly than the SDP offer, since entire media components (e.g. video in addition to speech) or codecs for a media component, which have been contained in the offer, may be rejected/modified in the answer, or the directionality of media components may be changed. Thus, if bearer resources are set up according to the service information derived from the SDP offer, they may exceed the real needs for the finally negotiated service.
Thirdly, as both the SDP offer and the SDP answer each only contain destination IP address and port information for IP flows in the direction towards the sender of this SDP, information from the SDP offer and answer needs to be combined to configure all required IP flow filters.
Fourthly, the SDP offer is quickly followed by an SDP answer in normal message exchange. If control information both from the offer and the answer is provisioned towards the policy enforcement node, the related signalling load is doubled between policy control node and the policy enforcement node as compared to current procedures, where only the SDP answer triggers such a provisioning. In addition this may also lead to additional bearer level, e.g. GPRS (General Packet Radio Service), signalling to configure bearer resources accordingly.
In view of the above, it is evident that there exist several problems in the field of policy control in networks regarding both currently specified and recently discussed procedures.
Thus, a solution to the above problems and drawbacks is needed for providing an effective policy control in networks such as for an IP Multimedia Subsystem as a non-limiting example of a network.